home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Subtle bug in ODFContaine < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.7 KB  |  [TEXT/ttxt]
  1. Subject:     Subtle "bug" in ODFContaine
  2. Sent:        5/23/96 11:16 AM
  3. Received:    5/23/96 11:31 AM
  4. From:        Kirk Swenson, kswenson@mail.keypress.com
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. First, let me join in the chorus of favorable responses to ODF R1.  The
  9. improvements from d11 are even greater than I had expected.  In moving our
  10. part to ODF R1, however, I have stumbled across one minor problem that people
  11. might want to be aware of.
  12.  
  13. In ODF R1, ODFContainer's Content.cpp won't compile in CW8 if any of the CW8
  14. STL header files are included.  This makes it difficult to use STL containers
  15. as part of the content model for an embedding part, since PartMaker uses
  16. ODFContainer as the template for embedding parts.
  17.  
  18. The problem is in the following lines in CBaseContent::RedrawProxies():
  19.  
  20.     FW_CAcquiredODShape updateShape = CalcUpdateShape(ev);
  21.     if (updateShape != NULL)
  22.  
  23. The template class that defines FW_CAcquiredODShape,
  24. FW_TAcquiredODRefCntObject, declares two operator!=() functions, neither of
  25. which handles a void* operand automatically.  When an STL header file is
  26. included, the compiler tries to bind the comparison to STL's global
  27. operator!=() defined in STL's <function.h>, which generates a compiler error
  28. about incompatible operands.  (The line number given by the compiler for the
  29. error is in <function.h>, which makes it a bit tricky to figure out where in
  30. Content.cpp the problem is.)
  31.  
  32. The local fix is to replace the comparison with
  33.  
  34.     if (updateShape != (ODShape*) NULL)
  35.  
  36. or, for those who prefer the newer cast style
  37.  
  38.     if (updateShape != static_cast<ODShape*>(NULL))
  39.  
  40. This matches one of the operator!=() defined by
  41. FW_TAcquiredODRefCntObject<ODShape>, which forces the compiler to select the
  42. correct operator!=(), and everything compiles.
  43.  
  44. Alternatively, FW_TAcquiredODRefCntObject could be modified, perhaps by
  45. adding an operator!() which would compare against NULL automatically, and
  46. allow the above code to be rewritten
  47.  
  48.     if (!updateShape)
  49.  
  50. which prevents the client from having to know what the internal pointer
  51. really is.
  52.  
  53. The original code compiles correctly when STL header files are not involved
  54. because the compiler will coerce NULL to be an ODShape* if it doesn't see any
  55. better alternatives.  When it sees STL's global operator!=(), however, it
  56. tries to bind that way instead.  I haven't worked through the C++ operand
  57. resolution order to determine exactly why the global operator is preferred in
  58. this case, but that's what the compiler seems to be doing.
  59.  
  60. This detail aside, however, we are very pleased with ODF R1.
  61. Keep up the good work!
  62.  
  63. Kirk Swenson
  64. Senior Software Engineer
  65. Key Curriculum Press
  66. Emeryville, CA
  67. kswenson@keypress.com
  68.  
  69.